The digital entertainment industry has taken a lead in creating realistic real time environments where the user can interact with the environment and others. Real time 3D graphics is also used in the industry where it is used in many different areas such as medical and health care for visualizing of the human body and in telematics where it is used in navigation and positioning. The ever growing ability to create a more realistic world on a screen has also created a new field of training systems, serious gaming, where for example a fighter pilot trains before combat or a surgeon prepares himself before a complicated operation. The real time 3D graphics industry has also gone mobile with next generation mobile phones, which have the graphics and computing power to create stunning results.
The hardware is typically built around a Central Processing Unit (CPU)/and Graphics Processor Unit (GPU). The CPU is the unit controlling the interpretation of program instructions and their execution. It receives and sends data through input-output channels, retrieves data and programs from memory, and conducts mathematical and logical functions of a program. There are many alternative terms to a CPU, such as processor or embedded system. Other examples on equivalents are a Parallel Computing System or a Multi Processor System. The GPU is a specialized processor, designed to draw 3D graphics. As such, it's much faster for typical tasks involving 3D graphics than the processor is. Many other terms may be used for the GPU. The CPU/GPU are typically connected over a bus, such as AGP or PCIx on a PC system. Many GPU systems today have their own dedicated memory. This architecture can both be found in modern PC and workstations as well as future handhelds, mobile phones, game consoles and other similar units. The CPU and GPU on a PC are often connected through a high-speed bus such as AGP or PCIx. This design has created a breakthrough in graphics computer power since the GPU can be optimized to handle graphically intensive tasks. Since the GPU is task oriented the speed of the GPUs has increased faster than Moore's law. The trend is also that the CPU is either multicore and/or multiprocessor type with the ability to handle threads in parallel.
The industry growth has created a need for programmers' and developers' tools for doing rapid development of 3D applications. Today there are basically two different industry standards, OpenGL and Direct3D, which both offer a GPU and vendor independent way of communicating in a CPU/GPU environment. Direct3D is generally available for platforms from Microsoft Corporation. OpenGL is available on PC and workstations as well as handhelds, gaming consoles and embedded environments in the form of OpenGL ES. Both OpenGL and Direct3D have been designed as low-level abstractions close to the machine hardware. Due to low-level abstraction both OpenGL and Direct3D are complex and difficult to master. In a large and complex development environment with multiple developers this has become even more apparent. In such a development environment a single non-intended state change in OpenGL is likely to have a negative impact and it may crash the rest of the application. Several attempts to create a higher abstracted development model have been made based on Open GL but with varying results. One of the most novel ideas has been the idea representing the graphic data in a graph, known as a Scene Graph. The idea is that the developer attaches one or more transforms nodes to a root node and then a 3D object with a set of attributes defining the objects. This approach has been implemented both as script languages such as VRML, and as a programming APIs, for example in Java3D from SUN Microsystems. Both implementations have succeeded in reducing the complexity of the application development. A problem with the previous known scene graphs is a relatively high cost of speed during run-time. Another problem with the known scene graphs is that the developer does not have control of all aspects of rendering nodes and objects. Additionally there are other related problems with the previous known scene graphs that need to be solved to meet the developer community demands. A particular problem for many developers is the insufficient ability of the suppliers of the previously known scene graphs, and their related APIs, to adapt to the rapid development of the GPU and the ever increasing number of rendering algorithms.
Java3D has been designed to be inherently multithreaded and rendering order independent. When traversing a scene graph, the Java3D process starts from a virtual universal proceeds. The order of traversal is not defined and the actual location of the node has no meaning for the final result, only the path from the root to a leaf. The approach in Java3D is that the user describes a set of objects and their attributes in the scene graph. Further, the approach in Java3D comprises that the scene graph data is assembled and data is put into render bins. A similar approach can be found in graphs like VRML. Each render bin is then responsible for programming the rendering pipeline. The render bins are parallel structures and their internal order of execution is out of user's control and different threads often execute different bins.
This approach makes it very hard and often impossible for the developer to describe new novel rendering algorithms since the final result is order dependent. There is no natural way in the scene graph semantics to describe an algorithm. Thus making it difficult for Java3D developers to adapt to rapid development of the GPU and rendering theory. Developers dependent on new versions still strive to incorporate their needs and ideas. The difficulties also limit developers' ability to innovate and create new effects never seen before.
The patent application publication US2001/0030647 describes a system and a method for processing of scene-graph-based data and/or programs. Structures and threads may be configured to convey information about state changes through the use of messaging. The system may include support for messaging between threads, messaging with time and/or event stamps, epochs to ensure consistency and ancillary structures such as render-bins, geometry structures and rendering environment structures. The patent application describes the Java3D API. The patent application describes a system that has the previously mentioned problems, such as that the Java 3D programmer does not have control over the rendering order of objects. Another remaining problem is that the programmer does not have the possibility to use a new algorithm from a GPU vendor unless supported by the Java3D API.
U.S. Pat. No. 6,683,9062 from Microsoft Corporation describes that semantics usage allows shaders to be authorised independently of the actual vertex data and accordingly enables their reuse. This allows developers to program the shaders in the assembly and high-level language with variables that refer to names rather than registers. By allowing this decoupling of registers from the language, developers can work on the language separately from the vertex data and modify and enhance high-level language shaders without having to manually manipulate the registers. This also allows the same shaders to work on different sets of mesh data, allowing the shaders to be reused. In general, semantics can be used as a data binding protocol between distinct areas of the rendering pipeline to allow more flexible workflow. However, even though user semantics enable a higher abstraction level, such as a description of uniforms, it does not address the use of a scene graph and states still have to be manually assigned to the rendering pipeline. An alternative term to rendering pipeline is programmable pipeline.
It is desired to have a method and system that supplies an API for 3D graphics development on a high abstraction level, that, to a great extent, is platform independent and allows programmers to work in scene graph environment, with the programmer controlling the rendering order, and the programmer has the ability to use the latest algorithms, such as features from the GPU vendor, without having to upgrade the system software such as Java3D.